Authentication is the process of verifying that a person or thing (e.g., computing system) is the person or thing that he/she/it claims to be. Authentication is used to ensure that from amongst all the persons and/or things that request access to specific items of software (e.g., applications, data files, etc.) only those persons or things that are approved to have such access are actually granted such access. The classic example of an authentication service is a module of software designed to ask a client for a userid and password.
Different types of authentication processes and procedures exist (e.g., RDBMS, Kerberos, Biometric Authentication, Unix Authentication, Windows NT authentication, etc.). FIG. 1 shows an architecture that is capable of performing a particular type of authentication process from amongst a plurality of available authentication services. According to the architecture of FIG. 1, in response to a user's attempt to use an application 101, an authentication service 102 is invoked to verify the identity of the user. The authentication service 102 includes a login context 103 and a collection of login modules 104.
The login context knows or understands which login module amongst login modules 1041 through 104N, is appropriate for the situation; and, causes the appropriate login module to be used to authenticate the user. Here, each login module can be viewed as corresponding to a different type of authentication process. For example, login module 1041 is a module of software for executing RDBMS authentication processes, login module 1042 is a module of software for executing Kerberos authentication processes, login module 1043 is a module for software for executing Biometric authentication processes, etc. If the login context 103 views Kerberos authentication procedures to be appropriate for the situation, the login context 103 invokes the Kerberos authentication module 1042 to authenticate the user.
An invoked login module executes its specific type of authentication process (e.g., with the help of a callback handler (not shown in FIG. 1), asks for a userid and password in accordance with a specific format). If it is determined that the user has provided acceptable credentials to very himself/herself/it, and if the verified user has been cleared for access, a favorable response is sent to the login context 103 by the invoked login module. The login context 103, in turn, favorably reports to whatever entity initially requested the services of the authentication service 102.
In one type of approach, a separate “user manager” service (also referred to as an “authorization” service), which is not shown in FIG. 1 for illustrative ease, keeps track of which users are permitted to reach which applications. Therefore, once the login module has verified the identity of a user, it passes the identity of the user to the user manager service. The user manager service verifies whether or not the user has the authority to reach the application that triggered the authentication procedures. If the user does not have authority, the login module is told as much by the user manager and an unfavorable response is forwarded up to the login context 103 and then up from the login context 103.
If the user does have the authority, the login module is told as much by the user manager and a favorable response is sent to the login context 103 and beyond. Often, “principle information” is created for the user that is based on the authentication information collected by the login module (e.g., the user's password). Principle information is any information that identifies a user. Authorization (i.e., the process of determining whether or not a user has the authority to reach a protected area of software) is performed by correlating the user's principle information to the protected areas the user has been approved for access to.
FIG. 1 suggests that a particular application 101 invokes the authentication service 102. Although this is possible it is not necessarily the case. For example, a user's attempt to enter the container 100 within which the application resides may be sufficient to trigger the authentication service, the location of the user may be sufficient to trigger the authentication service, etc. The application 101 may be various forms of applied software such as, for example, a business logic application, a page, a servlet, one or more files (or software to fetch one or more files), etc.
A container 100 is shown in FIG. 1 as well. A container 100 is typically used to collect a plurality of applications. Here, the authentication service 102 is provided by the container itself for the use of its applications (and, as such, may be referred to as a “container-wide” authentication service). The security service's ability to invoke different types of authentication schemes is useful because the container's different applications may cause a need for different authentication schemes (e.g., a first application requires the use of a first type of authentication scheme, a second application requires the use of a second type of authentication service, etc.).